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1 SCOPE AND PURPOSE 

1.1 Scope 

This document presents an architecture for evolving DSL deployment and interconnection. It outlines a common 
methodology for delivering QoS-enabied applications to DSL subscribers from one or more Service Providers. 
The business framework and drivers justifying this architectural evolution are described in detail in WT-080. 

1.2 Requirements 

In this document, several words are used to signify the requirements of the specification. These words are often 
capitalized. 

MUST This word, or the adjective "REQUIRED", means that the definition is an absolute requirement 

of the specification j 

MUST NOT This phrase means that the definition is an absolute prohibition of the specification. 

SHOULD This word, or the adjective "RECOMMENDED", means that there may exist valid reasons in . 

particular circumstances to ignore this item, buf the full implications must be understood and 
carefully weighted before choosing a different course. 

MAY This word, or the adjective "OPTIONAL", means that this item is one of an allowed set of 

alternatives. An implementation that does not include this option MUST be prepared to inter- 
operate with another implementation that does include the option. 

2 PRODUCTS AND SERVICES 

2.1 Service Goals 

Despite efforts to unify the architecture of Service Provider connections and to provide common service tiers, 
there has not been general support for a unified architecture. This proposal intends to increase the interest in 
such an architecture by increasing the number of service parameters available as well as by making those 
parameters more dynamic. Aside from variable dynamic bandwidth, this new architecture includes Quality of 
Service (QoS) and multi-application/multi-destination selection. - 

Service Providers benefit in that they will only need to develop one set of system interfaces for any carrier that 
adopts this architecture. By subscribing to these interfaces, Service Providers will now be able to develop 
applications that can take advantage of variable bandwidth and better than "best effort* data traffic delivery. 
Subscribers will be able to realize greater potential of their broadband data connections. This means that a 
subscriber can still use their Internet access as it exists today; yet additional bandwidth on their DSL line can be 
used to deliver other applications, such as direct corporate access, video chat and video conferencing, and 
various content on demand, be it movies, games, software, or time-shifted television programs. Finally, these 
applications can be given QoS treatment, so that business access, online gaming, and casual Internet access 
all share bandwidth appropriately. Both subscribers and Service Providers will be able to decide among 
connections, who provides the best service for a specific application, and what applications add the most value. 

2.2 Product and Service Lists 

. This document presents a proposal for evolving DSL deployment and interconnection. It will outline a common 
methodology for delivering QoS-enabled applications to DSL subscribers from multiple Service Providers. 
These products and services are intended to address the mass market, and do not preclude additional niche or 
custom services that could be provided using the same infrastructure. Many of the current products offered 
today either can be adapted to contain or already do contain the necessary software needed to support the 
proposed architectures contained within this document. 

Also provided is a set of architectural requirements to support the proposed new service models. Some of the 
highlights include: 

♦ IP-based sendees and QoS 
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♦ A single network control plane 

♦ The migration of DSL to leverage newer, alternative transport technologies 

With this target architecture in mind, a transition plan that identifies an interim phase before reaching the target 
is also included. - 

The prevalent existing service model, where subscriber connections are delivered in a best effort fashion over- 
ATM PVCs will continue to exist. However, this service model cannot support many of the improvements and 
benefits desired, including IP QoS, bandwidth on demand, and utilization of newer, alternative transport options. 
This architecture supports the following service provider interconnection models, which are described WT-080: 

♦ Subscriber access using PPPoE aggregated into L2TP tunnels delivered to Network Service Providers. 

♦ Subscriber access using PPPoE or IP over Ethernet aggregated into VPNs delivered to Network Service 

♦ Subscriber access using PPPoE or IP over Ethernet aggregated into a common, public, QoS-enabled IP 
network and delivered to Application Service Providers. 

The DSL architecture and requirements put forward by this document enables the following products and 
services, which are described in WT-080. 

♦ Bandwidth on Demand 

♦ QoS/CoS on Demand 

♦ Many-to-Many Access 

♦ Content Distribution 

Network Service Providers will be able to benefit from the aggregation capabilities of the new DSL Access 
Networks described in this document. Specifically, this architecture will also permit: • 

The end-tc-end ATM PVC models, whether VPC or VCC, do not provide a 
scalable solution. L2TP and IP are used to provide better scalability and 
efficiency. 



Traffic Aggregation: 



♦ Improved Transport: 



Simpler Provisioning: 



♦ Differentiated Services: 



♦ Increased Access: 



Standard Connections: 



Currently most DSL transport is done over ATM connections. By offenng 
other transport options, like Packet over SONET (POS) and Metro Ethernet, 
this architecture can provide better scalability, reduced overhead, and 
increased flexibility over ATM. 

Because they are not directly linked to provisioning transport, L2TP and IP 
delivery models can reduce the level of per subscriber provisioning. 

Up until now, almost all DSL transport has been best effort delivery at a fixed 
rate. This new IP based architecture will permit Service Providers to offer 
differentiated treatment for certain traffic. 

In previous architectures, Service Providers could only reach those 
subscribers with whom they- had a direct relationship. These new 
architectures permit a subscriber to connect simultaneously to multiple 
Service Providers for a variety of services. Service Providers no longer need 
to be the sole provider to their subscribers. 

Up until now, each access provider has had their own set of interfaces for 
Service Providers. This proposal defines common interfaces for NSPs and 
ASPs. This means that the Service Provider need only develop a single 
interface to get all of these features for many access providers. Also, 
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subscriber connections will be similar among Access Providers, allowing 
common CPE to be more widely deployed. 

beTsS bJ ^Z^S^ Wi " re S\ a n6W S8t rf netW0rk mana 9 eme * interfaces. These interfaces will 
Zl *o Service Providers and Subscribers. Service Providers will be able to examine the network and 

Pr ° ViSi0ned NSPS ™" a,S ° 56 pr ° Vjded 30 interface t0 ^ and troubleshoot 

Subscribers will be provided mechanisms for requesting these new services and signaling specific needs. 
These requirements will support applications and services like: 



♦ Multicast audio and video media applications 

♦ Video on demand applications 



♦ Voice services 

♦ Interactive gaming 

♦ Variable bandwidth, both on demand (Turbo" button) and by application 

3 FUNCTIONAL ASSUMPTIONS 

3.1 Key Terminology 

The following definitions apply for the purposes of this document: 

Access Network The Access Network encompasses the DSL modems at the 

customer premises and their connection to the Access Node at the 
central office or remote site. 

Access Node The Access Node contains the ATU-C, which terminates the DSL 

signal, and physically can be a DSLAM, Next Generation DLC (NG- 
DLC), or a Remote Access Multiplexer (RAM). A DSLAM hub can be 
used in a central office to aggregate traffic from multiple remote 
physical devices, and is considered logically to be a part of the 
Access Node. When the term "DSLAM" is used in this document it 
is intended to very specifically refer to a DSLAM, and not the more 
generic Access Node. The Access Node provides aggregation 
capabilities between the Access Network and the Regional Network. 
It is the first point in the network where traffic on multiple DSL lines 
wjll be aggregated onto a single network. 

Broadband Remote Access Server (BRAS) The BRAS is the aggregation point for the subscriber traffic 

It provides aggregation capabilities (e.g. IP, PPP, ATM) between the 
Regional/Access Network and the NSP or ASP. Beyond 
aggregation, it is also the injection point for policy management and 
IP QoS in the Regional/Access Networks. 

Core Network The center core of the Regional Network. The functions contained 

herein are primarily transport oriented with associated switching or 
routing capabilities enabling the proper distribution of the data traffic. 

Downstream The direction of transmission from the ATU-C (Access Node) to the 

ATU-R (modem). 

Edge Network T he edge of the Regional Network. The Edge Network provides 

access to various layer 2 services and connects to the Regional 
Network core enabling the distribution of the data traffic between 
various edge devices. 

Layer 2 Tunnel Switch (L2TS) The L2TS provides a second layer of PPP aggregation beyond the 

L2TP Access Concentrator (LAC). PPP sessions are switched ' 
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Loop 



Many-to-Many Access Sessions 



PVC Bundle 



Regional Network 



Regional/Access Network 
Routing Gateway 

Subscriber 

Upstream 

User 



between L2TP tunnels and are further aggregated and delivered to 
the NSP. 

A metallic pair of wires running from the customer's premises to the 
Access Node. 

The ability for multiple individual users or subscribers, within a single 
premises, to simultaneously connect to-multiple NSPs and ASPs. 

Two or more ATM PVCs (called a "bundle") are co-terminated on 
router endpoints. Each bundle co-termination is bound to a single IP 
interface. That is, the two (or more) PVCs appear to be a single "link 
layer" to the IP layer and so share a single set of routes. DiffServ, 
TOS marking, or other IP QoS mechanisms are used to select which 
of the two or more PVCs to use in either direction. Currently PVC 
bundles apply only to routed, not bridged interfaces. 

The Regional Network interconnects between the Network Service 
Provider's network and the Access Network. A Regional Network for 
DSL connects to functional equipment at a central office such as an 
Access Node within an Access Network. The function of the 
Regional Network in this document goes beyond traditional 
transport, and may include aggregation, routing, and switching. 

The Regional and Access Networks. 

A customer premises functional element that provides IP routing and 
QoS capabilities. It may be integrated into or be separate from the 
ATU-R. 

The client that is purchasing the DSL circuit from the Service 
Provider and is receiving the billing. 

The direction of transmission from the ATU-R (modem) to the ATU- 
C (Access Node). 

Typically, a member, employee or guest at the Subscriber's, 
household or business using the DSL circuit capabilities. 



3.2 Broadband Provider Reference Definitions 

Generally services over a DSL access-based broadband network will be provided and supported by a number 
of different operational organizations. These organizations may be part of one company or more than one 
company. Leaving commercial issues aside, it is necessary to have a clear idea of the roles of the different 
organizations and how the functionality of equipment, network management, and test equipment can support 
their ability to discharge their roles for the benefit of the end customers. In order to prov.de a baseline with which 
to contrast, this document provides a common architectural view of DSL architecture in Figure 1. 
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Figure 1 - DSL Network Components 
(Voice components not shown for clarity) 



J 



Boxes in the figures represent functional entities - networks and logical components rather than physical 
elements. 

This traditional architecture is centered on providing service to a line or a loop. It is desired, however, to be able 
to provide services that are user-specific. Additionally, more than one subscriber can be present at the same 
premises and share a single loop. There is a need, therefore, to describe a slightly more complex situation, and 
hiding the common complexity shared with Figure 1, this description is provided in Figure 2 below. Note that the 
figure shows many-to-many access through a common Regional/Access network. It is used to simultaneously 
provide an Application Service! between an ASP Network and Usen at the same time and over the same U 
interface as it supports a Network Service 2 between NSP Network 2 and User 2 . 
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Figure 2 - Many-to-Many Access 



The figures show the key components of a DSL access-based broadband network. They indicate ownership of 
the components to different providing organizations. The role of these various providers is. indicated below: 

The Network Service Provider (NSP): 
♦ Includes Internet Service Providers (ISPs) and Corporate Service Providers (CSPs) 
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♦ Is responsible for overall service assurance 

♦ Mav provide CPE, or software to run on customer-owned CPE, to support a given service 



♦ 



♦ 
♦ 
♦ 
♦ 



. Provides the customer contact point for any and all customer related problems related to the provision of 
this service 

Authenticates access and provides and manages the IP address to the subscribers 
The Application Service Provider (ASP): 

Provides application services to the subscriber (gaming, video, content on demand, IP Telephony, etc.) 

Is responsible for the service assurance relating to this application service 

Responsible for providing to subscribers additional software or CPE which specific services may 

Provides the subscriber contact point for all subscriber problems related to the provision of specific service 

applications and any related subscriber software. 

Does not provide or manage the IP address to the subscribers 



♦ 
♦ 



♦ 
♦ 



♦ 
♦ 



The Loop Provider 

Provides a metallic loop from the Access Network equipment to the customer's premises 
Is responsible for the integrity of the metallic loop and its repair 

May also provide the Access Network Provider aggregated access to remotely deployed DSL equipment 
owned, operated, and maintained by the Loop Provider 

The Access Network Provider: 

Provides digital connectivity to the customer via the metallic Loop 

Is responsible for the performance and repair of the access transmission equipment 

The Regional Network Provider: 

Provides appropriate connectivity between the Access Network and the NSPs and ASPs 
Is responsible for Regional Network performance and repair 



3.3 Interfaces 

These interfaces are key to this architecture, and have been modified or expanded from historical architectures 
(except the U interface). 

3.3.1 A10-ASP Interface 

This reference point is between the Regional/Access Network and the ASPs g^™ 8 
interface will consist of a routed IP interface, that may be transported over Fast Ethernet Gflh^teJ, 
Packet over SONET (POS), or some other IP interface. The ASP has the end-to-end Service 
the customer for their specific application and is viewed as the "Retailer" of the specific service. Trouble reports 
for the specific service go directly to the ASP. 

3.3.2 A10-NSP Interface 

This reference point is between the Regional/Access Network and the NSP's POPs. The inters could be 
ATM, Fast Ethernet, Gigabit Ethernet, or Packet over SONET (POS). In the case of AlW»i 
may be multiplexed over a single VCC at this interface. Typically, the NSP has the e "f^ n f ^' ce 
responsibility to the customer and is viewed as the "Retailer" of the serv.ce. As the retorie oi the DSL sew.ce, 
trouble reports, and other issues from the subscriber are typically addressed to the NSP. Handoff protocols 
could include ATM VP/VCs, L2TP tunnels, and routed protocols using IP-VPNs. 



6 



DSL Evolution - Architecture Requirements for the Support of QoS-Enabled IP Services 



WT-081 



3.3.3 If Interface 

The U Interface is located at the subscriber premise between the Access Node and the Network DSL 
Termination Device. 

3.3.4 T interface 

The T Interface defines the interworking between the DSL modem/Routing Gateway and other CPE in the 
Customer Premises Network (CPN). The requirements for new vertical services over DSL require the addition 
of a Routing Gateway as the intermediate point between the DSL modem and the LAN Devices. The primary 
goal of this interface is to facilitate seamless transmission of IP packets in both a best effort approach as well as 
maintaining predefined QoS behavior or establishing dynamic 60S behaviors through a signaling mechanism. 
The DSL modem and Routing Gateway may or may not be a single device. 

4 REFERENCE ARCHITECTURE 

4.1 Logical Reference Architecture 

As noted in Section 3.2 above, the end-to-end DSL network consists of four providers. Of these providers, the 
two that this proposal most affects are the Regional Network Provider and the Access Network Provider. 
Historically the Regional Network has been a network of ATM switches, as shown in Figure 3. This is because 
the access to most Access Nodes is an ATM based interface. Some Access Networks even have their own 
ATM switches used to aggregate traffic from multiple Access Nodes. 




Regional / Access Network 



Figure 3 - ATM based Regional and Access Network Providers 

In this architecture, there are no mechanisms for limiting subscriber traffic except for per line profiles within the 
Access Nodes. As many DSL networks were deployed before the advent of the BRAS, almost all the Access 
Network Providers use fixed speed profiles in the Access Nodes to limit upstream and downstream traffic. Even 
if the Service Provider were to attempt to. send more traffic into the Regional Network than the Access Node is 
set to permit, the Access Node will police the downstream traffic. Since most Internet-based applications use 
TCP as the transport protocol, the traffic rejected at the Access Node will trigger TCP back-off : effectively 
throttling the downstream bandwidth. As such, most Service Providers also shape downstream traffic at the 
subscriber-selected bandwidth. However, the desire to move to a rate adaptive bandwidth model means that 
both the Regional and Access Networks could be vulnerable to traffic overloading. A means to control upstream 
and downstream traffic is needed as this architecture evolves. 
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Many times the physical components of the Access Nodes are daisy-chained, sharing the bandwidth of the 
aggragating cfc* A. shown in Figure 12 in Section 4.2.5.4, there are numerous ways that MLwbbs 
devices can be interconnected to the first ATM switch. While historical measurements have shown that the 
•SSTdS? uses no more than a small fraction of sustained bandwidth, the fact 

are offered more and more high bandwidth applications, the average sustained bandwidth per subscnber ove 
fhese Smile" connections is going to increase. As per subscriber bandwidth ^S^^SS^ 
Network Provider will also need to scale bandwidth and provide subscnber-level granularity . ATM VPs do not 
provide the granularity necessary to offer per application QoS on a per subscnber basis. 




Regional / Access Network 



Figure 4 - IP Enabled Regional Network 
As a result other devices need to be added to the Regional Network to provide better aggregation of subscriber 

S Tart several options for doing this, most of which involve IP enabling the Reg-onal Network as 
shown in Figure 4. Subscribers that use native IP, which is a routable protocol, can be aggregated at the IP level 
fnto a Virtual LAN (VLAN) or Virtual Private Network (VPN) for handoff to their associated Semoe ft^der 
Those subscribers that use variations of the Point-tc-Point Protocol (PPP), such as PPPoA (PPP over ATM) 
and PPPoE (PPP over Ethernet), can be aggregated at either the PPP or the IP layer. 
If the aggregation is done at the PPP layer, then these PPP sessions will need to be forwarded over ■ « i routable 
protocol such as Layer 2 Tunneling Protocol (L2TP). When the new s ubscriber aggrega . on elemen . 
fijnctioning in this mode, it is referred to as an L2TP Access Concentrator or LAC The other option for PPP 
based subscriber is to also terminate the PPP session and assign IP addresses to the subscnbers. This traffic 
wouTd then be collected into a VLAN or VPN as with native IP traffic. When performing PPP Termination and 
Aggregation (PTA), the box is typically called a Broadband Remote Access Server or BKAb. 
As more and more DSL aggregation is performed at the IP layer rather thanthe ATM layer, additional fransport 
options may be added. In addition to ATM, Ethernet and Packet over SONET are also options for P£"g«t 
There are various metropolian Ethernet solutions available in speeds of 10 Mbps (B^^^JJ* 
Ethernet), or 1 Gbps (Gigabit Ethernet or GigE). Metropolitan Ethernet connections have the added benefits of 
being less costly than Frame Relay, ATM, or private line circuits. 

These new network elements also need to be able to function as the first tier ATM "W^J*^ 
the Access Node is now directly connected. As such, these devices will also need to handle ATM evel . 
aggregation and switching and need to function as an adjunct to the existing ATM network^ Sin^tJ^y are IP 
aware 9 they can also serve as the Label Edge Router (LER) that is required ^^^^^SSS 
Multi Protocol Label Switching (MPLS) aware. This would be shown in Figure 4 by collapsing the BRAS and 
ATM switch into a single multi-protocol device. 
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4.2 Logical Elements and Interfaces 

4.2.1 Application Service Provider Network 

4.2.1.1 Description 

The Application Service Provider (ASP)is defined as a Service Provider that shares a common infrastructure 
provided by the Regional/Access Network and an IP address assigned and managed by the Regional Network 
Provider. This is a new application of DSL service. The Regional Network Provider owns and procures 
addresses that they, in turn, allocate to the subscribers. ASPs then use this common infrastructure in order to 
provide application or network services to those subscribers. For example, an ASP may offer gaming, Video on 
Demand, or even filtered Internet access, or access to VPNs via IPsec or some other IP-tunneling method. The 
ASP service may be subscriber-specific, or communal when an address is shared using Network Address Port 
Translation (NAPT) throughout a Customer Premises Network (CPN). It is envisioned that the ASP environment 
will have user-level rather than network-access-level identification, and that a common Lightweight Directory 
Access Protocol (LDAP) directory will assist in providing user identification and preferences. Logical elements 
used by ASPs typically include routers, application servers, and directory servers. The relationship between the 
ASP Network, the A10-ASP interface, and the Regional Network is shown in Figure 2. 

4.2.1.2 Capabilities 

The capabilities of the ASP include but are not limited to the following: 

♦ Authenticating users at the CPN 

♦ Assignment of user profile or preference data 

♦ Assignment of QoS to service traffic 

♦ Customer service and troubleshooting of network access and application-specific problems 

♦ Ability to determine traffic usage for accounting purposes and billing 

4.2.2 A 10- ASP Interface 
4.2.2.1 Functionality 

As shown in Figure 5, the A10-ASP interface defines the interworking between the ASP Network and the 
Regional/Access Network. This is not a traditional interface. However, in order to provide more technical and 
business options to would-be broadband content and application providers this document defines a way for a 
Service Provider to attach a server, servers, or entire network to a common infrastructure directly accessible by 
DSL subscribers. Providing the A10-ASP interface is intended to promote content on demand, IP telephony, 
gaming, and other Quality of Service (QoS) or Bandwidth on Demand (BoD) applications without the need to 
deploy or manage an IP infrastructure. This also conserves IP addresses, as a single address can be used to 
gain access to all the services and providers that opt to share this infrastructure. 
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Application 



ASP Network 




Regional / Access Network 



A10-ASP 

Figure 5 - A10-ASP Interface 
4.2.2.2 Communication Protocols 

This interface MUST support IP networking connectivity to the DSL subscribers. Several QoS and BoD use 
cases exist: 

1 . Best effort IP networking is used with no additional QoS or information required. 

2. Differentiated Services (Diffserv) QoS is provided in order to establish a higher class of service - oriented 
toward higher throughput, packet precedence, or lower latency. 

3. RSVP-like (Resource reservation Protocol) signaling is used to receive bandwidth guarantees, BoD grants, 
or dynamic admittance to a strict priority Diffserv class. 

The communications protocol stack is shown in the following Figure 6. 

A10-ASP 



RSVP-like Protocol 



Diffserv-enabled IP 



ATM, Ethernet, 
Frame Relay, POS 



Various PHY 



Figure 6 - ASP Protocol Stack with QoS 

The ASP obtains an IP connection over a typical data link layer as described earlier. More <W**« ™* SP 
actually obtains a 10 Base-T, 100 Base-T, or GigE connection to the Reg.onal/Access Network wrth.n a co- 
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location or hosting facility. The Regional/Access Network provider statically assigns the addresses, and MAY 
provide address blocks to the ASP. 

Network Layer 

The network layer interface MUST support IP version 4 in accordance with IETF RFC 1042. 
The network layer MAY support IP version 6 in accordance with IETF RFC 2460. 
The network layer interface SHOULD support IP multicast. 

The network layer interface MAY support IP precedence based on Diffserv Code Point (DSCP) markings, in 
accordance with I ETF RFC 3 1 40. 

The network layer interface MAY support IP precedence based on RSVP-iike signaled QoS. 
Data Link Layer 

The data link layer SHOULD support Ethernet in hosting or co-location sites. 
The data link layer MAY support ATM, Frame Relay, and/or POS. 
Physical Layer 

The physical layer interface MUST support the following: 

• Ethernet PHY for 1 0 Mbps, 1 00 Mbps, 1 Gbps 

• DS1,DS3 

• OC3, OC12, OC48 

4.2.3 Network Service Provider Network 
4.2.3.1 Description 

The Network Service Provider (NSP) is defined as a Service Provider that provides some service that requires 
extending a Service Provider-specific Internet Protocol (IP) address. This is the typical application of DSL 
service today. The NSP owns and procures addresses that they, in turn, allocate individually or in blocks to their 
subscribers. The subscribers are typically located in Customer Premises Networks (CPNs). The NSP service 
may be subscriber-specific, or communal when an address is shared using NAPT throughout a CPN. This 
relationship among the NSP, A10-NSP interface, and Regional/Access Network is shown in Figure 2. NSPs 
typically provide access to the Internet, but may provide access to a walled garden, VPN, or some other closed 
group or controlled access services. L2TP and IP VPNs are typical A10-NSP interface arrangements. 

The capabilities of the NSP include but are not limited to the following: 

• Authenticating network access between the CPN and the NSP network 

• Assignment of network addresses and IP filters 

• Assignment of traffic engineering parameters 

• Customer service and troubleshooting of network access problems 

4.2.4 A10-NSP interface 

4.2.4.1 Functionality 

As shown in Figure 7 and Figure 9, the A10-NSP interface defines the interworking between the NSP and the 
Regional/Access Network provider. This document offers the following Layer 2 and Layer 3 options for this 
interconnection. 

4.2.4.2 Communication Protocols: L2TP Connection 

This interface MUST support the Layer 2 PPP connection service supported by L2TP. Using Figure 8 as a 
reference, subscribers MUST be placed into L2TP tunnels in one of the following methods: 
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1 . L2TP tunnels MAY be established or provisioned statically between LNS and the LAC or through an 
intervening Layer 2 Tunnel Switch (L2TS). 

2 L2TP tunnels MAY be established dynamically using RADIUS in order to determine which users to add to 
various L2TP tunnels, including potentially new ones. As before, these may be directly between LAC and 
LNS or via L2TS. 




A10-NSP 



Figure 7 - A10-NSP Interface Supporting L2TP Connection 
One or more sessions can be established to NSPs and are chosen by the fully qualified domain name (FQDN) 
of the accessing subscriber. 

Business models that require limiting subscriber access to a single NSP SHOULD be supported through 
administrative limits on the FQDN routing established by the Regional/Access Network provider on behalf of 
one or more NSPs. Subscribers SHOULD be able to establish multiple L2TP access sessions to the same or to 
different NSPs. 

The RADIUS response MAY be used to determine the bandwidth profile for its access session. 
The communications protocol stack is shown in the Figure 8. 
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Figure 8 - L2TP Protocol Stack 

While L2TP over IP MUST always be used, as opposed to L2TP delivered directly over ATM or Frame Relay, 
various IP transport options can be provided by the Regional/Access Network provider or selected by the NSP 
according to availability, regulation, and economics. 

Network Layer 

The network layer interface MUST support IP version 4 in accordance with IETF RFC 1 042. 
Data Link Layer 

The data link layer SHOULD support ATM. 

The data link layer MAY support Ethernet, Frame Relay, and/or POS. 
Physical Layer 

The physical layer interface MUST support the following: 

♦ Ethernet PHY for 1 0 Mbps, 1 00 Mbps, 1 Gbps 

♦ DS1.DS3 

♦ OC3,OC12,OC48 



4.2.4.3 Communication Protocols: IP Routed Connection 

This interface MUST support the Layer 3 IP routed connection. Using Figure 9 as a reference, subscribers 
MUST be placed into IP routed networks in one of the following methods: 

1 . IP address pools MAY be established or provisioned statically. 

2. IP addresses MAY be provided in pools that are distributed dynamically by the Regional/Access Network 
provider. 

3. IP addresses MAY be established dynamically using RADIUS. 

4. IP addresses MAY be assigned from named pools in cases where the NSP opts to allocate addresses out 
of two or more pools based on subscriber-specific information. 
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NSP Network 




Regional / Access Network 



A10-NSP 



Figure 9 - A10-NSP Interface Supporting IP Routed Connection 

In every case, RADIUS MUST be used between the BRAS (or a potential RADIUS proxy) and an NSP- 
designated AAA system or systems to authenticate subscriber access to the routed network. 
In most cases, the IP routed network will be comprised of many IP-VPNs that support sharing of the 
Regional/Access Network at the IP layer. 

Because multiple services are potentially provided across the U interface, access to the IP network will be 
governed, as with L2TP, using the FQDN of the accessing subscriber. Subscribers MUST be able to establish 
multiple access sessions to the same or to different NSPs. Business models that require restricting the network 
access MUST be supported through administrative limits on the FQDN routing established by the 
Regional/ Access Network provider on behalf of one or more NSPs. 

If an NSP connects to the Regional/Access Network in several places, the A10-NSP interface SHOULD support 
BGP4. 

Several QoS and BoD use cases exist: 

1 . Best effort IP networking is used with no additional QoS or information required. 

2. Diffserv QoS MAY be supported and MUST be used in order to establish a higher class of service - 
oriented either toward higher throughput, or lower latency. 

3. RSVP-like signaling MAY be supported and MUST be used to receive bandwidth guarantees, BoD grants, 
or admittance to a strict priority Diffserv class. 

The communications protocol stack is shown in Figure 10. 
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Figure 10 - Routed IP Protocol Stack with QoS 
IP MUST always be used; however, various IP transport options can be provided by the Regional/Access 

mY^to JS* Ssef t0 3UthenfiCate USer3 ' SH0ULD 66 ^ to set ^P-desired filters, and 
Network Layer 

The network layer interface MUST support IP version 4 in accordance with IETF RFC 1042. 
The network layer interface SHOULD support IP multicast. 

Jffi? RF? Z SUPP ° rt ' P PreC6denCe ^ ° n DWSSrV C ° de P ° int (DSCP > ma ^s, in 

The network layer interface MAY support IP precedence based on RSVP-like signaled QoS. 
Data Link Lay er 

The data link layer SHOULD support ATM 

The data link layer MAY support Ethernet, Frame Relay, and/or POS. 
Physical Laver 

The physical layer interface MUST support the following: 

♦ Ethernet PHY for 1 0 Mbps, 1 00 Mbps, 1 Gbps 

♦ DS1, DS3 

♦ OC3, OC12, OC48 



4.2.5 Regional/Access Network 

^^^^ h y W0I i C ° nS] ^ ? f thS RS9i0nal Netw0rk ' Broadband Remote A «*ss Server, and the 
Access Network as shown in Rgure 1 1 . Its primary function is to provide end-to-end transport between the 

25 ZXETT 3n . d th ! NSP ° r ASP ' ^ Re 9i°nal/Access Network may also provide SheSS^ons 
such as QoS and content d.stribution. QoS will be provided by tightly coupling trafficUngineering SSSST 
Network K wrth »* capabitties of the BRAS. Depending on the type mSfZSm of ?se SSn 
? PU f h8d , ° Ut in the ^gional/Access Network TtLn others As a resutt 
functionalrty to support content distribution could be located at different points within the Regional/Access 
Network, but will not be located between the BRAS and the subscriber Kegional/Access 
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Regional / Access Network 



Figure 11 - Components of the Regional/Access Network 



4.2.5.1 Regional Network 

The Regional Network connects the BRAS and Access Network to NSPs and ASPs. The Regional Network 
may transport traffic using ATM, Ethernet, or IP MPLS. Within these networking technologies, the Regional 
Network MUST provide scalable traffic engineering capabilities to preserve IP QoS. 

4.2.5.2 Broadband Remote Access Server 

The BRAS performs multiple functions in the network. Its most basic function is to provide aggregation 
capabilities between the Regional/Access Network and the NSP/ASP. For the aggregation Internet traffic the 
BRAS serves as a L2TP Access Concentrator (LAC) tunneling multiple subscriber PPP sessions directiy to an 
NSP or switched through a L2TS. It also performs aggregation for terminated PPP sessions or routed IP 
session by placing them into IP VPNs or 802.1 Q VLANs. The BRAS also supports ATM termination and 
aggregation functions. 

Beyond aggregation, the BRAS is also the injection point for providing policy management and IP QoS in the 
Regional and Access Networks. The BRAS is fundamental to supporting the concept of many-to-many access 
sessions. 

Policy information can be applied to terminated and non-terminated sessions For example, a 

may be applied to a subscriber whose PPP session is aggregated into an L2TP tunnel and .s not terminated by 

the BRAS. However, sessions that terminate on (or are routed through) the BRAS can receive per flow 

treatment because the BRAS has IP level awareness of the session. In this model, not only can the aggregate 

bandwidth for a customer be controlled but also the bandwidth and treatment of traffic on a per application 

basis. 

The delivery of content has shifted from content that was more download intensive with lower bandwidth and 
best effort quality to one that is more real-time in nature, requiring higher bandwidth .with .higher qua ^ Some of 
the higher bandwidth applications include Video on Demand (VoD) for movies, Multicas \ {Broadcast TV), and 
MPEG Unicast video. Given the BRAS's proximity to the edge of the network and its ability to support IP 
services the BRAS MUST also provide support for content distribution and efficient use of multicast services. 
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Some high level functional requirements are for the BRAS are listed below. This list is not comprehensive and 
additional requirements for QoS are listed in Section 5. 

♦ The BRAS MUST be able to aggregate PPP sessions in the L2TP tunnels. 

♦ The BRAS MUST be able to switch PPP sessions between L2TP tunnels. 

♦ The BRAS MUST be able to terminate PPPoE sessions and assign routing attributes based on subscriber 
profile. 

♦ The BRAS MUST support authentication using RADIUS. 

♦ The BRAS MUST support IP over bridged Ethernet (IETF RFC 2684). 

♦ The BRAS MUST support address allocation using Dynamic Host Configuration Protocol (DHCP). 

♦ The BRAS SHOULD support ATM VC/VP pass-through switching functions. 

♦ The BRAS MUST support termination and aggregation of ATM VCs. 

♦ The BRAS -SHOULD support the following ATM classes of service: UBR, UBR+, CBR, VBR-nrt, VBR-rt . 

♦ The BRAS MUST allocate downstream bandwidth based on policy configuration across ATM, PPP, 
Ethernet, and IP technologies. 

♦ The BRAS MUST mark IP QoS fields for upstream and downstream traffic based on policy configuration. 

♦ The BRAS MUST police IP QoS markings and bandwidth allocation based on policy configuration. 
4 The BRAS MUST support queuing and prioritization based on IP QoS marks. 

♦ The BRAS MUST support traffic engineering for networking technologies including ATM, MPLS, and 
Ethernet. 

♦ The BRAS MUST support diffserv-aware hierarchical traffic scheduling that will allow it to manage potential 
congestion over 2 ATM hops in the Access Node. If the BRAS does not include the ATM switching 
function, then it must support yet an additional layer of hierarchical shaping to manage congestion of the 
ATM switch trunks. 

♦ When operating in an IP-routed mode, the BRAS MUST provide multicast support by implementing: 

♦ Host Extensions for IP Multicasting defined in IETF RFC 1 1 12 

♦ Internet Group Management Protocol, Version 2 (IGMP v2) defined in IETF RFC 2236 

♦ Protocol independent Multicast-Sparse Mode as defined in IETF RFC 2362. 

♦ MBGP as per IETF RFC 2858 

♦ The BRAS SHOULD support LAN interfaces for the local attachment of content distribution servers. 

4.2.5.3 Access Network 
Description 

The Access Network refers to the network between the ATU-R and the ATU-C/Access Node. The protocols 
between these devices are well defined and this recommendation does not attempt to alter them. 



4.2.5.4 Access Node 
Description 

The Access Node contains the ATU-C, which terminates the DSL signal. Physically, the ATU-C can be 
deployed in the central office in a DSLAM, or remotely in a remote DSLAM (RT-DSLAM), Next Generation 
Digital Loop Carrier (NG-DLC), or a Remote Access Multiplexer (RAM). A DSLAM hub can be used in a central 
office to aggregate traffic from multiple remote physical devices, and is considered logically to be a part of the 
Access Node. 

The Access Node provides aggregation capabilities between the Access Network and the Regional Network. It 
is the first point in the network where traffic on multiple DSL lines will be aggregated onto a single network. 
Traditionally the Access Node has been primarily an ATM concentrator, mapping PVCs from the ATU-R to 
PVCs in the ATM core. The role of the Access Node will change slightly in order to 'open up' the DSL line for IP 
QoS services. The current responsibility of policing ATU-R to ATU-C PVCs to the subscribed line rate will be 
moved from the Access Node to the BRAS functional element The Access Node will set line rate for each PVC 



17 



DSL Evolution - Architecture Requirements for the Support of QoS-Enabled IP Services WT-081 



at the synch rate (or slightly less) of the ATU-R and A7U-G- "mis will make the maximum amount of subscriber 
bandwidth available for IP Qos services while retaining the ability to police individual sessions/flows as required. 
Various physical Access Node configurations are shown in Figure 12, with brief names for the configurations 
listed in Table 1 . 

The important aspect is that the daisy chaining never exceeds a depth ,of more than two ATM 
switching/multiplexing points in the Access Node. This becomes important as IP is leveraged to manage traffic 
flows through the access node. In section 5, a mechanism to manage IP traffic through ATM devices 
(hierarchical shaping) is described. As the depth of non-ATM aware nodes increases in the access node, the 
complexity of implementing a hierarchical shaping grows as well. In order to minimize this complexity, the 
number of ATM hops should be kept to a minimum. This architecture relies on a small, predictable number of 
ATM hops in the Access Node so that the BRAS can manage the downstream QoS. This architecture seeks to 
manage the congestion in legacy Access Nodes by careful shaping in the BRAS so that congestion does not 
occur in the Access Node. Rather, multiple hierarchies in the BRAS egress shaping will account for trunk 
bandwidths in the Access Node. Note also, that if the BRAS does not incorporate the ATM switching 
functionality, an additional layer of hierarchical traffic shaping will be necessary to manage the trunk to the ATM 
switch. 
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Figure 12 - Access Node Architecture Variations 



Table 1 - Access Node Architecture Variation Descriptions 



Reference # 


Description 


• 1 


Access Node 


2 


Hub Access Node 


3 


Collocated Subtended Access Node 


4 


Remotely Located Subtended Access Node 


5 


Subtended Remote Access Node 


6 


Subtended DLC Located Access Node 


7 


Aggregated DLC Located Access Node 
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4.2.6 U Interface 



4.2.6.1 



Functionality 

The U interface is defined as the interface between the Access Network and the CPN. This interface refers to 
%£?£2T? ?i P ^f re the ATU - R (DSL M0dem) is ,ocated and »» Access Network where the 
NeS mti 'the CPN indUdeS the ^P 315 ™ 65 and P rotocols 1031 CT0SS between the Access 

4.2.6.2 Communication Protocols 

As shown in Figure 13 the U interface defines the interworking between the CPN and the Regional/Access 
Network. This interface MUST support the bidirectional delivery of data for all the new product and service 
definitions as well as for existing (legacy) products and services 





Regional / Access Network 



Figure 13 - U Interface 

Although the first Network Element connection in the network is at the Access Node, the U interface must 
support the transparent flow of protocols from the DSL Modem to the BRAS. 

♦ l^V i r SSf US I SUp P 0r{ at least one A ™ A^ 5 PVC Per CPN using PPPoE and/or IP over Ethernet 
(lb I h RFC 2684) configured using DHCP (for IP over Ethernet). A second ATM AAL5 PVC MAY be 

ZZ^T^l^™? fPP iications - optional second PVC will require that the DSL modems support 

pv ?k ^ri CS - ? the 6Vent 2 PVCs are su PP° rted « is desired that they could be treated as a 
PVC bundle. Additionally as the standards to support the bridged, multi-service traffic emerge for PVC 
bundles, this architecture may require their support. 

♦ The U interface MUST support Diffserv Code Points (DSCP) per IETF RFCs 2474 and 3260 enablinq 
application-layer QoS signaling. a 

♦ The U interface MAY support signaled QoS, based on RSVP-like protocols 

♦ The U interface MUST support the ability to dynamically push IP routes back to the customer PC or Routing 
tote WW ^ ^ t0 Pr ° Vide r ° UteS t0 ** RG - The RG iS n0t expected t0 P rovide 



The communications protocol stack is shown in the following figure. 
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Figure 14 - U Interface Protocol Stack 

Network Layer 

The network layer interface MUST support IP version 4 in accordance with IETF RFC 1042. 

The network layer interface MAY support IP precedence based on Diffserv Code Point (DSCP) markings, in 

accordance with IETF RFC 3140. 

The network layer interface MAY support IP precedence based on RSVP-like signaled QoS. 
The network layer interface MUST support PPPoE per IETF RFC 2516. 
Data Link Layer 

The data link layer MUST support Ethernet encapsulation in accordance with IETF RFC 2684. 
The data link layer MUST support ATM in accordance with ATM Forum standards. 
Physical Layer 

The physical layer interface MUST support G.dmt, and its related standards. 



4.2.7 Customer Premises Network 

The Customer Premises Network (CPN) is defined at its highest level as the location where the ATU-R is 
located and terminates the physical DSL signal, and where the subscriber's computers and other devices are 
interconnected.. The initial DSL deployments focused on single user architectures where the CPN constituted : 
single PC connected directly to a DSL modem. This paradigm of service will continue to be supported and 
improved, but must be extended to support advanced features that go beyond the single user model. To 
support enhanced features (multi-user, gaming, VoIP, video, etc), the CPN must evolve to support the 
networking and management of devices and services within the home or business location. 

From a network perspective, the CPN is the ultimate target of the services provided by the Service Provider 
(NSP or ASP). The CPN includes the networking environment and protocols that are resident in the premises. 
CPN may imply coexistence of different link and physical layer technologies such as radio, power line 
transmission and Ethernet, but is assumed to have access to outside networks (via DSL). The terms devices 
and appliances refer to.the collection of end terminals that can reside on the CPN, either temporarily (laptops, 
palm pilots, foreign devices etc.) or permanently, such as desktops, security, and climate control systems. 
Devices may or may not be individually addressable and reachable from other devices, inside or outside the 
CPN. Some devices may communicate with proxies that then can relay or translate state or configuration 
information for these end devices. 
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4.2.7.1 DSL Modem 

Description 

The DSL Modem contains the ATU-R and terminates both DSL and ATM. It may or may not be integrated with 

f^^S Gat f a y ( R G> funcfconalrty. If it is not integrated, it will be used in a mode that is SSdte 
as a simple bndge modem. 

Capabilities 

The capabilities of the DSL Modem MUST include but are not limited to the following: 

♦ 2 ATM AAL5 PVCs - in order to be able to support the U interface service option of using 2 PVCs Note 

SioSal PVCs m ° demS Wi " lik6ly ^ additi ° nal S6rViCe driVSrS that W0Uld requir ® them t0 su PP° rt 

♦ UBRUBR+ and VBR-rt ATM classes of service 

♦ Per-VC queuing, separate priority queues for ATM classes of service 



4.2.7.2 Routing Gateway 

Description 

Sin^^ 68 ^H^L ' everage 3 Routin9 Gatewa y ( RG > device tnat P rovides functionality beyond that of a 
not L i5L t ^'I^! oc!f 3 dSViCe f0r pr0Viding enhanced slices within the CPN. The RG may or may 
£1^ 5 + ""5 the D , SL m0dem funCti0n - ln the inte 9 rated scenario - the device terminates the DSL signal 

t T d D P rovid ! s an interface t0 otner equipment located within customer premises. In the non- 
ntegrated case the RG .s physically separate from the DSL modem and adds functionality to the CPN 

2!E?c T S 8 > , . m0d6m - SinCe ^ e inte 9 rated R G has knowledge of the CPN and its access to external 

Soth^ tght !L COn !i 01 ° f Q ° S f ° r rea ' time app,ications than ^ be P° ssible in a non-integrated 
archrtecture. Both integrated and non-integrated RG are supported in this specification. 

Capabilities 

Sowing 0 " 1 thiS Q ° S ~ enabled arcnitect ure, the capabilities of the RG MUST include but are not limited to the 

♦ IP routing between the CPN and the Access Network 

♦ Multi-user, multi-destination support: Multiple simultaneous PPPoE sessions (started from the RG or from 
devices ms.de the CPN) in conjunction with non-PPP encapsulated IP (bridged) sessions per IETF RFC 

♦ Network Address Port Translation (NAPT) 

♦ Local DHCP 

♦ Support for major applications and protocols in the presence of NAPT and firewall (e g SIP H 323 IPsec> 

♦ Dynamic MTU negotiation ' 

♦ Packet segmentation based on traffic/queue type 

♦ PPPoE pass though 

♦ Multiple queues, with the appropriate scheduling mechanism 

♦ IPQoS 

♦ Classification and shaping of IP flows 

♦ Drffserv 

♦ Management interface 

♦ RSVP-like signaling 

♦ Support for real time services (Voice, Video) 

♦ Re-classification capabilities 

4.2.7.3 Networking Technologies 

Description 
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The CPN will support the transparent transmission of IP packets. It is expected that the CPN wilt be a hybrid of 
technologies that may include Ethernet, phone line networking, power line networking, wireless networking, and 
others. 

4.2.7.4 LAN Devices 
Description 

Devices inside the CPN that are served by the DSL Modem and RG, and connected by the various Networking 
Technologies are referred to as LAN Devices. These may include, but are not limited to, PCs, laptops, 
networked set-top boxes, and Internet.Appliances. 

4.2.8 T Interface 

4.2.8.1 Functionality 

As shown in Figure 15, the T interface defines the interworking between the DSL modem/RG and the LAN 
Devices. This interface MUST support the bi-directional delivery of IP packets between the RG and other CPE 
as well as the ability to assign addresses to other CPE using DHCP. The other major functional requirement 
placed on the T interface includes identifying and supporting ; °QoS flows" as defined in Section 5. The primary 
goal of this interface is to facilitate seamless transmission of IP packets in both a best effort approach as well as 
maintaining predefined QoS behavior (Diffeerv) or establishing dynamic QoS behaviors through a signaling 
mechanism (like RSVP). 
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Figure 15 - T Interface 
4.2.8.2 Communication Protocols 
Network Layer 

The network layer interface MUST support IP version 4 in accordance with IETF RFC 1 042. 

The network layer interface MUST support IP precedence based on differentiated service (Diffeerv) code points 

in accordance with IETF RFC 3140. 

The network layer interface MUST support IP precedence based on RSVP-like signaled QoS. 



Data Link Layer 
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The data link layer MUST support Ethernet in accordance with IEEE 802.2/802.3 (Ethernet) and as shown in 
Figure 16. 

The data link layer SHOULD support Ethernet virtual LANs (IEEE 802.1 Q). 

The data link layer SHOULD support Ethernet precedence of LAN traffic (IEEE 802.1 D/Q). 

The data link layer MUST support PPP over Ethernet in accordance with IETF RFC 2516 and as shown in 
Figure 17 

Logical Link Controller (LLC) Sublayer 

The logical link controller sublayer subinterface MUST support Ethernet in accordance with IEEE 802.2. 
Medium Access Control (MAC) Sublayer 

The medium access control sublayer subinterface MUST support Ethernet in accordance with IEEE 802.3. 
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Figure 16 - IP over Ethernet 
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Figure 17 - IP over PPP over Ethernet 

5 QUALITY OF SERVICE 

5.1 Introduction n 

DSL architectures and products are predominately engineered for the support of best effort Internet traffic. Many 
NSPs desire the ability to improve their best effort product by using different levels of . 
Additionally, there are other market drivers pushing the Regional/Access Network to ^^^^ 
services that require functionality beyond a best effort grade of service. Such s ^^*f^" d ~ 
services, gaming, bandwidth on demand, and corporate VPN access as referen c ed .n ^ 2iln wtoto 
support IP services effectively, the network must be IP aware and prov.de support that scales as the number ot 
DSL subscribers and the number of applications per subscriber increases. 



5.1.1 Goals 

The goal of this section is to describe the mechanisms for introducing: 

♦ A method for providing differentiated best effort traffic engineering 

♦ Per flow IP QoS into the Regional/Access Network 

Both of thesegoals leverage the existing capital investments yet effectively meet the goals for supporting 
differentiated non-real time and real-time IP applications. 

One goal of the architecture is to enable more flexible bandwidth allocation to «£*^ b ^ to allow 
both the customer and the various Service Providers to participate in defining the bandwidth that will be made 
r^^£«E This bandwidth can be provided at deferent rates J^^^SSS^S^ 
service orders, but also on demand in near real time using mechanisms ^ 
interfaces or by using signaling protocols. It should be noted that this is st.ll best effort bandwidth - there .s no 
guarantee that an application 4n make use of the maximum bandwidth, in other words there are no throughput 
guarantees - only that the possible maximum rate might be increased. 

Real-time applications have concerns beyond bandwidth, like jitter and latency whicf ' * 
manaae when the DSL line rate slows down. Other applications, while may not be real time, have delivery 
Smente (no jackets dropped) that cannot be assured by bandwidth alone. It is a goal to manage multiple 
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applications over a small number (1 or 2) of ATM PVC(s) between the ATU-R and BRAS and provide the 
characteristics that both real-time and non-real time applications require. 

5.1.2 Assumptions 

Existing Regional Networks have a large embedded base of ATM equipment that is not IP aware. This 
equipment will be leveraged to the extent that it is technically and economically feasible. 

5.2 Best Effort Traffic Engineering 

Today's DSL access and Regional Networks are typically engineered to a single over subscription ratio picked 
by the various providers. This has served.the market well, but may need to be enhanced as service diversity 
expands and scope broadens. The concept for best effort traffic engineering is that an NSP might be able to 
select an over subscription policy, and that the various NSPs can use that as a tool for providing different grades 
of service, even in an otherwise best effort model. Using this feature, one NSP may opt for highly over- 
subscribed infrastructure in order to provide an extremely cost-effective service, while a second NSP might 
choose a much less over subscribed approach in order to provide a better user experience or a premium 
service. 

5.2.1 Theory of Operation 

Best effort traffic engineering (TE) makes use of MPLS TE, ATM VP or VC, and L2TP features in order to 
provide a specific over subscription rate for that NSP. 

As shown in Figure 18, traffic flowing between NSPi and CPNh is shaped to a large asymmetric configuration 
through the Regional/Access Network. At the same time, traffic flowing between NSP 2 and CPN 2 is shaped to a 
smaller symmetric configuration.. Finally, ATM or Diffserv techniques can be used at the A10-NSP interface in 
order to divide the total bandwidth at the interface among potentially disparate tunnel types that traverse it. 
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5.3 QoS Architecture - A two-phase approach 

While a signaled perflow lP QoS mechanism is the ultimaie goal of this architecture, the technical and 
economic feasibility of such a build out can not be justified in the near term. Instead, a 2-phase approach is 





Regional / Access 
Network 
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suggested that leverages incremental IP awareness associated with ATM level traffic engineering. In the first 
phase IP aware network elements are added to the network that in conjunction with ATM traffic engineering 
can manage IP flows through non-IP aware devices. The Dfiserv model is ^ged to pnontae a nd *jpe. 
traffic through ATM devices. The bandwidth that a subscriber receives will no longer be determined by the DSL 
svnch rate alone. Instead, both the physical and IP layers will be leveraged. Most importantly, phase 1 
significantly increases the IP layer functionality of the Regional/Access Network while not requiring massive re- 
deployment of capital and re-engineering of the network. 

Phase 2, however, will require more enhancements to the Regional/Access Network by eliminating or 
enhancing some ATM elements/functions and further increasing the IP capabilities. IP stgnaled QoS is 
introduced in this phase. 

5.3.1 Phase 1 QoS Mechanisms 

Phase 1 largely leverages the existing broadband Regional/Access Network as shown in Figure 3^ This network 
is generally IP unaware. In order to efficiently add IP awareness to the network without upgrading the ATM or 
AcSss node base, two enhancements are required: Within the network the BRAS is leveraged to provide IP 
aware handling of traffic and, similarly, at the customer premises new CPE capabilities are deployed. 
When a subscriber purchases a differentiated service, this service MUST flow through the BRAS. To support 
differentiated services, the BRAS preserves IP QoS through the access node and to ^^™*J*™*^. 
shaping traffic based on the physical topology of the logical connection between the BRAS and the RG In order 
to accomplish this task, the BRAS MUST be able to perform packet classification and h.erarch.cal shaping and 
scheduling. 

Once the BRAS is capable of managing the traffic flow through the access node, there is no need for access 
node to restrict a subscribers connection speed at layer one (ADSL synch rate . Instead the access ^ 
should allow the ATU-R to synch up at its maximum rate. Access sessions will now be shaped and rate limited 
by the BRAS and can allow for multiple sessions to be individually shaped based on the subscribed service. 

♦ The BRAS MUST support packet classification and scheduling in accordance with Diffserv. 

♦ The BRAS MUST support hierarchical shaping and scheduling for the control of traffic through the access 
node and any other intervening devices that do not have IP awareness. 

The effectiveness of using hierarchical shaping across non-IP aware devices «J C ^'»^^* 
devices and the amount of non-BRAS controlled traffic increases. As a result, the BRAS function should be 
located as close to the access node as possible from an ATM hop perspective. The BRAS function MAY be 
integrated into the access node. 

In order to preserve an IP flow's characteristics, the customer CPE must be involved in the QoS architecture 
This is especially true when dealing with traffic destined for the upstream DSL connection. This connection is 
typically the slowest link and most likely to incur congestion and add delay and jitter within the service. To 
maintain fair but effective through put over this link the RG MUST support packet classification and scheduling 
in accordance with Diffserv. The RG MUST support fragmentation based on queue status and type. 
The typical DSL customer is connected to the Regional/Access Network via a single ATM AAL5 PVC. This 
single PVC should be leveraged to the extent possible using the capabilities descnbed above. Some 
applications or network topologies may require a more stringent level of QoS between the BRAS and the 
customer premises. A second ATM AAL5 PVC MAY be provisioned for services that require extremely tight 
delay/jitter tolerances. The number of PVCs per customer SHOULD NOT exceed 2. 
To support bandwidth on demand products or other differentiated services that implicitly require a*Btonal 
bandwSth on demand, a subscriber's access sessions SHOULD be shaped and policed *£^"«* G 
instead of solely by the DSL ATU-R and ATU-C. This change is accompanied by changing the ATUs to allow 
them to synchronize at or near their maximum rate. Since we allow for multiple simultaneous access sessions, it 
MUST be possible to modify the shapers and policers on one or more sessions at the same time. The policy 
data for the classification and shaping of traffic at the RG is provided at service configuration and is not a real 
time capability. The policy data for the classification and shaping of traffic at the BRAS can be provided at 
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lYrterf^^ 9 "^ 00 ° r be dynamically configured via a Common Open Policy Service-like (COPS) 



Phase one assumes that the Regional/Access Network provider has established an IP-based architecture 
similar to that shown in Rgure 4. This figure can be combined with Figure 2 in order to support the end-to-end 
v.ew of QoS that follows. That combination is presented in Figure 1 9 
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Figure 1 9 - QoS Topology 

The two critical points where IP-QoS is required are the BRAS and the CPE (RG). Intervening elements (like 
DSLAMs) are not envisioned to become layer-3 routers, and this architecture assumes that they will not be 
nSt^f 6 ?1 J** mana9e con 9 estion - ™ s arrangement supports multiple business relationships and 
by ^ singl^provider Van ° US **** t0 Vari ° US WBh ° Ut feqUirin9 a " ServiC6S t0 be provided 

nSZlZ ISSl by 030 alS ° be Subdivided in to 2 ^b-phases. The first sub-phase 

m I £2? 3 t,r ? Dlffeerv would be provided trough static provisioning. The second sub-phase 
hrn 2Sf 66 3 * ubsec > uent t,me with a d yn^ic mechanism for changing the Diffserv QoS parameters 
through the use of a policy-based networking enhancement. . 

Phase 1A 
Assumptions: 

• In this phase there will be multiple BE NSP connections with few (1 or 2} EF sessions for real time 
applicat.ons (voice, Video conferencing). There will be little or no AF traffic - as applications would 
appNcation * 3 pre ~ confi 9 ured AF classes rather than requesting one that suits the 

" 22*- EF f P i iCati0 / 1 iS 9 uaranteed at 3 time (user performs the CAC across real time applications) 
Within an application domain it is the application's responsibility to perform the CAC 

• SScpe" ' S Perf0rmed at **■ RG on a session basis or acce Pted via markings attached to packets 

• Performing dynamic per-application classification requires a 5-tuple classifier to be pushed down to the 
RG and is not likely in the short term. 

• The DSLAM modems are allowed to synch at the max rate both upstream and downstream 

• Hierarchical shaping is performed at the BRAS to provide IP QoS congestion mechanisms for the 
downstream path. Similar policing is performed in the upstream path. 

• Packet-by-packet QoS requires- being in the PTA (or bridged 2684) model at a given element. 

Characteristics: 

1 • • Multi-user multi-destination is supported 

• IP QoS is leveraged at the RG and BRAS 
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The RG and BRAS are configured with common set of traffic profiles 
RG is configured by manufacturer or during installation (install CD) 
Statically assigned BE and EF queues will be supported in the RG. 

o Optional are statically assigned AF queues that could support 3 or 4 popular streaming 

arrangements or potential Gold/Silver/Bronze services. This option will require defining Diffserv 

classes that will be applicable across envisioned future services. 
Profiles define what rate traffic should be shaped to and what queuing behavior should be used. 
Profiles will also determine the valid DSCPs. 

A small number of shapers will be defined for the various connection speeds (i.e. 1.5x265; 1.5x d84; 
384x384;768x512) rvoi u „„ ... 

Sessions are individually shaped based on profile and share the aggregate DSL synch rate. If the total 
BW per profile exceeds the available synch rate then they share the BW in a "fair 1 manner among 
similar QoS service classes. ...,«. 
If the RG initiated the session/and it is authenticated, then it is told which pre-provisioned profile to use. 
Various potential protocols and mechanisms to do this have beeadiscussed at the DSLF. Note, rf a 
CPE device behind the RG initiates a PPPoE session then it remains PPPoE through the RG, and is 
BE traffic by definition. (Even if it becomes a PTA connection at the BRAS) 

In either a PTA or L2TP model the BRAS will police traffic in the upstream direction and shape traffic in 
the downstream direction. 

BRAS shaping, policing, and marking is done on a per session basis, not per application. However, the 
diffserv queues may be arranged within an access so that various aggregate service classes can be 
provided to applications that indicate which class of service they desire. The application needs to set 
the DSCP properly in order to make use of this function. •• 

o An end-to-end PPP session is given a BE treatment, but can be shaped (e.g. 1 .5x256). 

o A single, additional PPP or 1483 session is used to access the ASP network. 
The BRAS profiles are updated through provisioning, not signaling. 

New profiles are added/updated in the RG by the customer manually configuring the device or by 
downloading a new SW image 



Phase 1B: 
Assumptions: 

• Builds on the capabilities in phase 1 A 

. This phase enhances the granularity of the classification and population of policies in the RG. 
. Multiple sessions to multiple destinations each with multiple applications that may require drfferent QoS 
treatment 
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Figure 20 - Phase 1 with Policy-based profiles 



Characteristics: 

• When an NSP access session is authenticated the NSP may provide a profile indicator associated with 
that session in its response to the BRAS. 

• Once the BRAS receives the profile indicator, it retrieves the full profile from the Policy Server and 
appends the profile Information to the response sent to the RG. This step allows coordination among 
NSp and ASP profiles. 

• No single ASP authenticates the ASP access session, so a profile for that session is put together by 
the Policy Server and is based on various ASP subscriptions associated with that access. 

• ASPs can update the profile either through subscription or through a dynamic protocol. 

• Subscription profile information as well as DSL sync rate and user preferences are stored in the Policy 
Server and accessed using LDAP. 

• The Policy Server is responsible for managing potentially, conflicting ASP and NSP profiles and 
subscriptions and also creates billing data for services. 

• The profile is populated in the elements in near-real time (no reset or "reboot" required). 

• Diffserv marking and queuing behavior on RG is performed on 5-tuple matching (SA, DA, SP, DP, PI) 
as well as the mapping of access sessions into various 5-tuple "equivalent" classes. For example, 
PPPoE access through a RG will continue to be given BE treatment. 

5.3.1.1 Diffserv Requirements 

RG 

The RG requirements below only apply to the support of differentiated services. 

The RG MUST be the central point for controlling traffic within the customer premises and traffic destined for the 
Access Network. 

The RG MUST support Diffserv marking and reclassification in accordance with IETF RFC 2474. 

The RG MUST support Diffserv queuing for the Assured Forwarding (AF) and Expedited. Forwarding (EF) 
classes in accordance with IETF RFC 2597 and IETF RFC 3246 for carrying real time traffic. The exact AF 
classes supported will be described in future revisions to this document. 

The RG MUST support multiple queues with the appropriate scheduling mechanism to effectively implement 
Diffserv queuing behaviors (e.g. strict priority, Weighted Fair Queuing). 

The RG MUST be configured with the classification parameters for mapping traffic into a given Diffserv Per Hop 
Behavior (PHB) during service configuration. 

The RG MUST support fragmenting large data packets in the Best Effort (BE) and AF queues when packets are 
present in the EF queue. 

The RG MUST support an EF window timer. The EF window timer is required to support real time applications 
that exhibit a more bursty nature (e.g. VoIP with silence suppression) so that BE and AF packets continue to be 
fragmented even when EF packets are not present. 

When no packets are queued in the EF class for a duration longer that the EF window timer, the BE and AF 
packets MUST NOT be fragmented unless required for other reasons (negotiated MTU size). 

If multiple PVCs are present, the RG MUST support the mapping between a Diffserv Code Point (DSCP) and a 
specific PVC. (Using a PVC bundle is the desired way to meet this requirement.) 

BRAS 

The BRAS MUST support Diffserv marking and reclassification in accordance with IETF RFC 2474. 
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The BRAS MUST be able to police the use of DSCPs received from customer traffic and remark traffic as BE if 
it does not match the customer profile data. 

The BRAS MUST support Diffserv queuing for the Assured Forwarding (AF) and Expedited Forwarding (EF) 
classed Taccordan^with IETF RFC 2597 and IETF RFC 3246. The exact AF ^-^^.jj* 
described in future revisions to this document.. These queues are defined wrth.n the conte^ofthe DSLAM 
connectivity between the BRAS and the access node in affect managing the access node s downstream 
bandwidth. 

The BRAS MUST support multiple queues per user with the appropriate scheduling mechanism to effectively 
implement Diffserv queuing behaviors (e.g. strict priority, Weighted Fair Queuing). 
The BRAS MUST support the mapping of DSCP to MPLS LSP, VLAN, ATM VP, or other traffic engineering 
capabilities in the Regional Network. 

The BRAS MUST support fragmenting large data packets in the Best Effort (BE) and AF queues when packets 
are present in the EF queue. 

The BRAS MUST support an EF window timer. The EF window timer is required to support real time 
applicSTons that exhibk a more bursty nature (e.g. VoIP with silence suppression) so that BE and AF packets 
continue to be fragmented even when EF packets are not present. 

When no packets are queued in the EF class for a duration longer that the EF window timer the BE and AF 
packets MUST NOT be fragmented unless required for other reasons (negotiated MTU size). 
If multiple PVCs are present, the BRAS MUST support the mapping between a Diffserv Code Point (DSCP) and 
a specific PVC. (Using a PVC bundle is the desired way to meet this requirement.) 

5.3.1.2 Traffic Engineering Requirements 

' In order for the BRAS to effectively manage IP traffic through layer 2 devices, the BRAS MUST have awareness 
of the all of the traffic that is traversing those layer 2 elements. This can be fcompl.shed to 2 ways_The first 
and most straightforward method is for all traffic destined for the access node to flow through the BRAS 
enabling it to shape the traffic accordingly. In cases where this is not possible then the amount <* aggregate 
resources that is not under the control of the BRAS must be subtracted from the resou ces *a ' ^ BRAS h as 
under its control and be factored into the shaping and scheduling functons. The traffic 
control of the BRAS MUST be traffic engineered in a way that it cannot consume resources above the amount 
that the BRAS is aware of. Engineering around the BRAS incurs risk and must be done with care. 

5.3.1.3 Admission Control 

Network level admission control is not required in this phase. Admission control MAY be provided at the 
application layer. That is, the application can restrict the number of active sess.ons per access node and per 
customer premises. 

5.3.2 Phase 2 QoS Mechanisms 

The architecture for the second phase of the QoS enhancements is not fully defined in the following section. 
This section is included for illustrative purposes and will be fully defined in future documents. 
Phase 2 adds per IP flow resource reservation capabilities in the Regional/Access Network. Phase ,2 ^ntinues 
to leverage the RG and BRAS as the IP QoS managers of the access node. Rather than simply ' manag ng the 
aggregate scheduling of Diffserv resources, the BRAS will be able to perform per flow adm.ss.or , control 
ensuring that resources are never over booked. Diffserv will continue to be ^ 6 ^^ B ^°' cess 
scalability reasons. Keeping per flow resource reservation limited to the access portion of the Reg.onal/Access 
. Network will limit scalability/performance issues known with prior end-to-end reservation schemes. 

In this phase: _ , . 

Applications, located in any of the reference networks, request service or resources of the 
• Regional/Access network (e.g. through SIP, RSVP or some other RSVP-like mechanism . 

The RG and BRAS are involved in requests for services and resources in the network based on a per- 
application need (e.g. they monitor or proxy SIP invite messages or RSVP messages). 
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• . The BRAS acts as an RSVP border proxy and queries the Policy Server. It responds based on the 
network availability of traffic engineered resources (MPLS - TE, ATM VP, etc) and customer profile. 

• QoS service profiles can be applied to the BRAS and RG based on the requested application need. 

5.3.2.1 Signaled QoS Requirements 

BRAS 

The BRAS MUST support an RSVP-like protocol for the assignment of resources. When resources are not 
available at any point under its control the BRAS MUST block the admission of the session and provide 
feedback to the initiating host. 

The BRAS MUST know the DSL synch rates of the ATU-Rs that are connected to the access nodes that it 
manages. Based on a given ATU-R's DSL synch rate and customer profile the BRAS must manage the 
admission of sessions to that customer premises. An external policy/management server MAY feed this 
information to the BRAS. 

The BRAS MUST be able to intercept RSVP and application layer (e.g. SIP) messages that are not addressed 
to it and use these messages in making admission decisions. 

The BRAS MUST support mapping reservation requests into Diffserv PHBs and managing the PHBs as 
reservable resources. 

CPE 

The CPE requirements below only apply to the support of differentiated services. 

The CPE requesting differentiated services MAY be integrated with the ATU-R. Non-integrated CPE devices will 
also be supported (e.g. IP Phones, PC running video conferencing software, set top boxes, etc). 

The CPE MUST support IP layer signaled QoS similar to the IETF RSVP specification. These messages MUST 
be addressed to the destination host and MUST NOT be addressed directly to the BRAS. 

The CPE MUST NOT make any admission decisions. 

5.3.2.2 Diffserv Requirements 
BRAS 

The BRAS MUST conform to the requirements listed in section 5.3.1 .1 

The BRAS MAY accept policy information regarding how to manage Diffserv resources from an external entity. 
CPE 

The CPE MUST conform to the requirements listed in Section 5.3.1 .1 

If the signaling messages indicate the DSCP to be used by a session requesting access, the CPE MUST use 
the specified DSCP. 

The CPE MAY accept policy information regarding how to manage Diffserv resources from an external entity. 

5.3.2.3 Traffic Engineering Requirements 

The RSVP-like mechanism described only has resource knowledge of the local access node and does not have 
an end-to-end picture of the connection. As a result, the interconnection network within the Regional/Access 
Network (beyond the BRAS) MUST support traffic engineered to provide support for enhanced services. It is 
expected that within the core of the Regional/Access Network that aggregate traffic engineering techniques can 
efficiently serve the needs of enhanced applications. 

The Regional/Access Network MAY support MPLS TE. 

The Regional/Access Network MAY support ATM level TE. 

The Regional/Access Network MAY support Diffserv. 
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5.3.2.4 Admission Control 

Per-flow admission control MAY be performed at the BRAS. Admission ^decisions are made based on resource 
availability AND subscriber profile data. Both of these parameters may be sent to the BRAS via an external 
policy/provisioning server. j 

Application level admission control MAY be applied in addition to the network based admission control. 

6 SERVICE LEVEL MANAGEMENT 

6.1 Introduction 

Service Level Management is intended to provide 3 levels of benefit - increasing over time: 

♦ To provide a list of the salient network performance and operational metrics that might be used in a Service 
Level Objective (SLO) or Service Level Agreement (SLA). 

♦ To provide a standard definition of such metrics so that its meaning would be common when used by 

♦ r P rovide extoSne values that are driven by architectural considerations where f^^J^^' 
while it is NOT the intention of this document to set the SLO or SLA for Network Delay (Latency) any 
network that purports to support Voice over IP (VoIP) will need to have a maximum delay that .s wrthm the 
bounds necessary to support VoIP. 

6.2 Network Performance Metrics 

1 . Network Availability - The percent of time that the Regional/Access Network is avail J'e for subscribes to 
connect. This metric is defined on some time basis, such as a month, a week, or a year An SLA should 
So specify not the entire network but the section of the network for which the ^onam^ Ue^ 
Provider is responsible. For example, the Regional/Access Network Provider is not response for NSP 
problems. 

2 Network Delay (Latency) - The time it takes for a data packet to traverse the Regional/Access Network, 
Som! end-to-end or edg/tUdge. Latency is defined in milliseconds and can be a one-way or round-tnp 
delay. 

3 Message Delivery - The ability of the Regional/Access Network to transmit traffic at the negotiated speed. 
' Some applicable measurements are packet loss). These metrics must have a time base as well. 

4. Network Jitter - The variance of network latency. Jitter is defined in milliseconds. 

6.3 Operational Metrics 

1 . Mean Response Time - The time it takes the Regional/Access Network Provider to respond to submitted 
reports of trouble 

2. Mean T.me to Restore Service - The measurement of the Regional/Access Network Provider's ability to 
restore service within the negotiated interval 

3. Ordering System Reliability - The measurement of the consistent availability of ordering system. 

4. End-User Installation Guarantee - TheTneasurement of the Regional/Access Network Provider's ability to 
- meet negotiated order due dates. 

7 SERVICE MANAGEMENT 

The architecture proposed in this document clearly needs management systems to provide to antral is _ 
necessary to support the underlying service "building blocks". The following lists are example . o 
Joints that management systems MUST support. Network elements and Service Providers wj use these new 
data elements for service provisioning and data delivery. It is expected that the Operajons and Network 
Management working group of the DSL Forum will provide contributions to augment this section. ■ 
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7.1 Subscribers 

Because of the changes in how DSL is provisioned and managed, there are a number of new data points 
must be tracked for each subscriber. Among these are: 

♦ Maximum sustainable subscriber bandwidth 

♦ Maximum number of sessions allowed 

♦ Permitted destinations 

♦ Default protocol 

♦ Default destination 

♦ Default bandwidth 

♦ Single host or subnet needed 

♦ Restricted subscriber (single destination only) 

♦ Total reserved bandwidth 



7.2 Service Providers 

Because of the changes in how DSL is provisioned and managed, there are more details needed per Service 
Provider. When various choices listed for an option, these are to be considered as examples only and not a 
definitive list of the choices for a given option. 

♦ Minimum bandwidth needed 

♦ Minimum QoS level 

♦ Various protocol metrics 

♦ Subscriber protocol (IP, PPPoE) 

♦ Protocol (IP, L2TP, ATM) 

♦ Authentication 

♦ IP address assignment 

♦ Transport 

♦ Maximum simultaneous sessions 
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AAA 

AAA 


Authentication, Authorization, and Accounting 


A AT f 

AALj 


ATM Adaptation Layer 5 


ADSL * 


Asymmetric Digital Subscriber Lme 


a r: 

At 


Assured Forwarding 


A 1>T 

Arl 


Application Program Interface 


AKr 


Address Resolution Protocol 


A CD 

Abr 


Application Service Provider 


ATM 


Asynchronous Transfer Mode 


ATMARP 


ATM Address Resolution Protocol 


ATMF 


ATM Forum 


ATU-C 


Access Termination Unit - Central Office (at Access Network end) 


ATU-R 


Access Termination Unit - Remote (at customer end) 


B-NT 


Broadband Network Termination 


BE 


Best Effort 


BGP 


Border Gateway Protocol 


dOU 


Bandwidth on Demand 


BRAS 


Broadband Remote Access Server 


CBR 


Constant Bit Rate 


LU 


Central Office 


COPS 


Common Open Policy Service 


CoS 


Class of Service 


CPE 


Customer Premises Equipment ' 




Customer Premises Network 


CSP 


Corporate Service Provider 


DHCP 


Dynamic Host Configuration Protocol 


Diffserv 


Differentiate Services 


Fit C" 


Digital Loop Carrier 




Domain Name Service 


DS1 


Digital Signal level 1 (1.544 Mbps) 


DSCP 


Differentiated Services (Diffserv) Code Point 


DbL 


Digital Subscriber Line 


DSLAM 


Digital Subscriber Line Access Multiplexer 


TT7T 

br 


Expedited Forwarding 


PCD 


Encapsulating Security Payload 


E7"Yr\V1 

rQDN 


Fully Qualified Domain Name 


GFR 


Guaranteed Frame Rate 


lBGP 


internal Border Gateway Protocol 


IEEE 


Institute of Electrical and Electronics Engineers 


IETF 


Internet Engineering Task Force 


IGMP 


Internet Group Management Protocol 


IKE 


Internet Key Exchange 


TTi 
IP 


Internet Protocol 


IP sec 


Secure Internet Protocol 


ISP 


Internet Service Provider 


ITU-T 


International Telecommunications Union - Technical 


Lzlr 


Layer 2 Tunneling Protocol 


L2TS 


Layer 2 Tunnel Switch 




JLayer 2 over MrLS 


LAC 


Layer 2 Access Concentrator 


LAN 


Local Area Network 


LD 


Long Distance 


LDAP 


Lightweight Director}' Access Protocol 


LER 


Label Edge Router 


LLC 


Logical Link Control 
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LSP 


Label Switched Path 


LNS 


L2TP Network Server 


MAC 


Medium Access Control 


MARS 


Multicast Address Resolution Server 


MASS 


Multi-Application Selection Service 


MBGP 


Multicast Boarder Gateway Protocol 


MPEG 


Motion Pictures Expert Group 


MPLS 


Multi-Protocol Label Switching 


MS/MD 


Multi Session / Multi Destination Service 


MTU 


Message Transfer Unit 


NAPT 


Network Address Port Translation 


NG-DLC 


Next Generation Digital Loop Carrier 


NHRP 


Next Hop Resolution Protocol 


NSP 


Network Service Provider 


0C3 


Optical Carrier 3 


OSPF 


Open Shortest Path First 


PC 


Personal Computer 


PHB 


Per Hop Behavior ■-'*""• 


PHY 


Physical Layer 


POP 


Point of Presence 


POS 


< Packet over SONET 


PPP 


Point-to-Point Protocol - 


PPPoA 


Point-to-point Protocol over ATM 


PPPoE 


Point-to-Point Protocol over Ethernet 


PTA 


PPP Terminated Aggregation 


PVC 


Permanent Virtual Circuit 


PVP 


Permanent Virtual Path 


QoS 


Quality of Service 


RADIUS 


Remote Access Dial-In User Service 


RAM 


Remote Access Multiplexer 


RFC 


Request For Comments 


RG 


Routing Gateway 


RSVP 


ReSource reservation Protocol 


RT-DSLAM 


Remote Digital Subscriber Line Access Multiplexer 


SIP 


Session Initiation Protocol 


SLA 


Service Level Agreement 


SLO 


Service Level Objective 


SNAG 


Service Network Architecture Group (DSL Forum) 


SONET 


Synchronous Optical Network 


SVC 


Switched Virtual Circuit 


TCP 


Transmission Control Protocol 


TE 


Traffic Engineering 


. TR 


Technical Report (DSL Forum) 


TV 


Television 


UBR 


Unspecified Bit Rate 


UDP 


User Datagram Protocol 


VBR-nrt 


Variable Bit Rate - non-Real Time 


VBR-rt 


Variable Bit Rate - Real Time 


VC 


Virtual Circuit 


VCC 


Virtual Circuit Connection 


VLAN 


Virtual Local Area Network 


VoD 


Video on Demand 


VP 


Virtual Path 


VPC 


Virtual Path Connection 


VPN 


Virtual Private Network 


VoBB 


Voice over Broadband 
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VoIP Voice over Internet Protocol 

WFQ Weighted Fair Queuing 
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APPENDIX B SAMPLE MESSAGE EXCHANGE FOR BASIC 
SESSION ESTABLISHMENT WITH RSVP 

This appendix includes an example message exchange establishing a dynamic QoS enabled service. This 
message exchange is not complete. Other logical elements or signaling protocols may be required. While 
certain protocols are explicitly shown, it should be used as a high level reference that will be updated in 
subsequent versions of the document. 



Policy 
Server/ 
Session 
Manager 



BRAS 



Access Node 
ATM 



ATU-R 



CPE 
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